Practice Makes Perfect. And So Does a Database Practice.

To be honest, I don’t know how to write the title of this post since the ideas and theme I am going to write will not be fully unified. I’m just actually adding items to discuss when something with regards to what I need to write pops out of my sleepy brain. But for the love of potatoes, I’ll just write (type, actually) anything that I could think of.

First: Why does the word “potatoes” exist on the first paragraph?

Second: Should I continue typing provided that I don’t know if the next words could even make any sense?

Third: Why am I uneasy with other people’s generally agreed upon “best practices” on database design? Seriously, if the general circle of database creators follow these practices, I doubt if there wouldn’t be any problems down the line. There is no such thing as perfect program, so I could presume the imperfection of their system was due to their database structure. But nah, I must be sleepy. Don’t worry though, I will not force you to follow what my ideas are; this is just for my reference.

Here are the lists of the best practices that I am going to scrutinize for the sake of scrutiny:
Database Best Practices

Always have a PrimaryKey.
-Wait, what?! Given the fact that the column could never be used, the column consumes computer memory (and human memory as well) and that elephants could never jump, why in the world should a waste of electrons be added?!
-But to tell you frankly, I always have a primary key on my tables for the reason that I don’t know the answer to my question. It’s ironic that an iron cannot be ironed.

Use consistent column name suffixes and prefixes.
-It’s true that shit_Students table looks better than SouthHarmonInstituteOfTechnologyStudents for a very good reason, but Students is way better than the one with prefix for a very good reason. For example, the database schema will not only be used by S.H.I.T. for their system but will also be used by another school (presume we make a generic system), thus the prefix shit_ is useless and misleading. And if a new developer joins the team, and for some reason was not briefed on the project (which actually happened to me before), how would he know what shit_ stands for? Students as the table’s name is way okay-er since it’s readable and reusable.

Don’t use short column names.
ID as a field name is discouraged by them. Oh, come on, would you want your primary key column for table TheTableWithNoName be TheTableWithNoNameID? ID as a field name is tempting and is oftentimes correct. For objects generated from database, one would prefer TheTableWithNoName.ID than TheTableWithNoName.TheTableWithNoNameID. For as long as the thing is understandable, and very understandable, it’s already understood. True story.
-The thing is, I can’t find a good long table name aside from TheTableWithNoName. Sorry, was too sleepy.

Fourth: I realized that my post is already long enough, I need to sleep.

Fifth: I have nothing more. Maybe next time when there will be a brainstorm (storm in my brain) i could write longer. Good night. 🙂

Leave a comment